home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940148.txt < prev    next >
Internet Message Format  |  1994-11-13  |  17KB
  1. Date: Thu, 14 Jul 94 04:30:07 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #148
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Thu, 14 Jul 94       Volume 94 : Issue  148
  11.  
  12. Today's Topics:
  13.                  ARRL DIG COMM CONF. NEWS Rev 7/12/94
  14.             ARRL DIGITAL COMM CONF UPDATE BULLETIN 7/12/94
  15.                          Bridge vs. Repeater
  16.           Managing MSS and Window; IP encapsulation (3 msgs)
  17.  
  18. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  19. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  20. Problems you can't solve otherwise to brian@ucsd.edu.
  21.  
  22. Archives of past issues of the TCP-Group Digest are available
  23. (by FTP only) from UCSD.Edu in directory "mailarchives".
  24.  
  25. We trust that readers are intelligent enough to realize that all text
  26. herein consists of personal comments and does not represent the official
  27. policies or positions of any party.  Your mileage may vary.  So there.
  28. ----------------------------------------------------------------------
  29.  
  30. Date: Wed, 13 Jul 94 21:03:11 CST
  31. From: edf@bbs.wd0hxt.ampr.org
  32. Subject: ARRL DIG COMM CONF. NEWS Rev 7/12/94
  33. To: tcp-group@UCSD.EDU
  34.  
  35. ----- Forwarded message -----
  36.  
  37. When you think about it, unless you've got a clear freq of your own
  38. and don't have to share it with lots of other packet stations, a beam
  39. is discourtious UNLESS (!) it is also cophased with an omni.  Why?
  40. Beacuse the beam's back-door rejection will allow your station to keyup
  41. on top of other stations, resulting not only in increased band congestion
  42. but also avoidable interference that could lead to disconnections.
  43.  
  44. It's easy to cophase an omni to a beam.  Just run a 1/4 wavelength of
  45. 75 ohm coax to each 50 ohm antenna and to the transmitter 50 ohm line.
  46. Yes, beam (and omni) power output is 1/2 of what you get if just one
  47. antenna were online, but a good beam will make up for that and the omni
  48. will let you hear stations instead of keying up on top of them.
  49.  
  50. Just some Month of May Thoughts ...     :)
  51.                   
  52. 73 de Ron KC6RCO@KC6RCO.#ECMN.MN.USA.NA    Internet: ronm@kc6rco-nrom.ampr.org
  53.  
  54.  
  55. ----- End of forwarded message -----
  56. -------------------------------------------------------------------------------
  57. de                Ed Fairbairn            WD0HXT
  58. internet/amprnet = edf@bbs.wd0hxt.ampr.org
  59. pbbsnet = wd0hxt@wd0hxt.#msp.mn.usa.na
  60.  
  61. ------------------------------
  62.  
  63. Date: Wed, 13 Jul 94 21:13:38 CST
  64. From: tcp-info@bbs.wd0hxt.ampr.org
  65. Subject: ARRL DIGITAL COMM CONF UPDATE BULLETIN 7/12/94
  66. To: tcp-group@UCSD.EDU
  67.  
  68. ----- Forwarded message -----
  69.  
  70.        ARRL 13th ANNUAL DIGITAL COMMUNICATIONS CONFERENCE AUGUST 19-21
  71.  
  72. Do you operate a Digital mode (maybe Pactor, Packet, GTOR or AMTOR) now?  
  73. Do you find it difficult to keep up with the latest Digital technology?  
  74. Would you like to know more about Digital modes?  
  75. If you answered "yes" to any of these questions, then you should attend the 
  76. 13th Annual ARRL Digital Communications Conference.  Read on ...
  77.  
  78. The Conference will be held on August 19 - 21, 1994 at the Thunderbird
  79. Convention Center, 2201 East 78th Street in Bloomington, Minnesota.  
  80. Accomodations are available at the adjacent Thunderbird Hotel, at the many
  81. Hotels and Motels located within a short distance, and also at several area
  82. RV\camper campgrounds.
  83.  
  84. Enjoy a weekend of fun learning about the latest developments in TCP/IP, 
  85. PACTOR, AMTOR, PACTOR-II, CLOVER, G-TOR, PACKET, DSP, and imaging.  Participate
  86. in the nine forums about DSP, new HF modes, TCP/IP, VHF/UHF networking, BBS
  87. SYSOP issues and more.  A glance at the program (attached) will show many
  88. forums that will catch your interest!
  89.  
  90. One of the highlights of the conference will be the presentation of 18 
  91. technical papers on the many aspects of digital communications throughout the 
  92. day on Saturday.  A list of papers is attached.  You will receive a copy of 
  93. all papers presented.
  94.  
  95. Many demonstrations of the latest in hardware and software will be presented.
  96. When you leave, you will have an in-depth understanding of the latest digital
  97. communications advancements and techniques.  The Saturday evening Technical 
  98. Showcase will feature TAPR Special Interest Group meetings for BBS SYSOPs
  99. and on VHF/UHF network building and a nearly-mathless presentation of the
  100. design and implementation of DSP software for a high-performance HF DSP 
  101. modem based on the $99 TI DSK DSP evaluation module by Johan Forrer, KC7WW.
  102.  
  103. The Hospitality Room will provide the place to meet old friends ... and make
  104. new ones.  At the Saturday luncheon you will get to know "who's who" in
  105. digital communications.  Meet the Engineering staff of manufacturers like
  106. Kantronics and Timewave Technologies.  The optional Saturday evening diner 
  107. will provide another opportunity to make new friends.
  108.   
  109. If you want a break from the Conference, the Mall of America, with hundreds
  110. of unique stores, is located within easy walking distance.  Your family will
  111. enjoy Knott's Camp Snoopy theme park inside the Mall.  The renowned Minnesota
  112. Zoo is only a short drive away.
  113.  
  114. The Conference registration fee is $45 per person, which includes admission to
  115. all Conference activities, a luncheon buffet and a copy of the technical 
  116. papers.  An optional Saturday evening buffet is $20 per person additional.
  117. Registration deadline is August 12th.
  118.  
  119. For more information about the Conference or special Airline and Motel 
  120. discounts call or write:
  121.              ARRL Digital Communications Conference
  122.              C/O Paul Ramey WG0G
  123.              16266 Finland Avenue
  124.              Rosemount, MN 55068
  125.              Packet:     WG0G@WA0CQG.#MSP.MN.USA.NA
  126.              Telephone:  (612) 432-1640
  127.              Internet:    PRAMEY@RAM.NET
  128.  
  129. The host organization for the 1994 ARRL Digital Communications Conference is
  130. the TwinsLAN Amateur Radio Club.
  131.  
  132.        See YOU at the Digital Communications Conference August 19-21!
  133. ------------------------------------------------------------------------------
  134.          13th ANNUAL ARRL DIGITAL COMMUNICATIONS CONFERENCE
  135.                          PRELIMINARY PROGRAM
  136.  
  137. Friday,    August 19
  138.  
  139. TIME         ROOM       EVENT             
  140. Noon - 6    PM     TBD       ARRL    "Future    Modes" 
  141.                Committee meeting.
  142. Noon - 6    PM     TBD       ARRL    "219-MHz" Committee
  143.                meeting.
  144. 4    - 10   PM     Menominee Conference check-in.
  145. 6 PM - 11   PM     Menominee Hospitality & Demo area open
  146.  
  147. Saturday, August 20
  148. TIME         ROOM       EVENT
  149.  6:30 -     Noon     Menominee Hospitality & Demo area open
  150.  7:00 -     Noon     Menominee Conference Check-in.
  151.  8:00 -     8:15 AM Miami       Conference "Welcome"
  152.  8:30 -    10:00 AM Miami       Technical Paper Presentation
  153.  8:30 -    10:00 AM Yakima       Forum - Developments    in DSP
  154.                    For the Amateur.
  155.  8:30 -    10:00 AM Shoshone  Forum - TCP/IP - What's next?
  156. 10:00 -    10:15 AM All       Break
  157. 10:15 -    11:45 AM Miami       Technical Paper Presentation
  158. 10:15 -    11:45 AM Yakima       Forum - ARRL    Committee
  159.                Updates:  "Future Modes":
  160.                Moderator - Paul Rinaldo W4RI
  161.                and "219-MHz    Networking":
  162.                Moderator - Tod Olson K0TO"
  163. 10:15 -    11:45 AM Shoshone  Forum - Digital Data    (Voice 
  164.                and Image) Transmission
  165.                Method Developments.
  166. 11:45 -     Noon AM All       Break
  167. Noon  -     1:00 PM Miami       Buffet Luncheon (Included) 
  168.  1:00 -     5:30 PM Menominee Hospitality & Demo area open
  169.  1:15 -     2:45 PM Miami       Technical Paper Presentation
  170.  1:15 -     2:45 PM Yakima       Forum - High-Speed (above
  171.                1200    baud) data transfer
  172.                methods and networking
  173.                techniques.
  174.  1:15 -     2:45 PM Shoshone  Forum - HF Data Transmission
  175.                Methods - An    Over-view of
  176.                Current Modes and What's
  177.                Coming Next.
  178.  2:45 -     3:00 PM All       Break
  179.  3:00 -     4:30 PM All       Continuation    of all sessions
  180.  5:30 -     6:30 PM Miami       Buffet Diner    (Optional)
  181.  7:00 -    11:00 PM Menominee Hospitality & Demo area open
  182.  7:00 -    10:00 PM Miami       Tucson Amateur Packet Radio
  183.                (TAPR) Presents Special
  184.                Interest Groups:
  185.                   -    Packet BBS SYSOPs
  186.                   -    VHF/UHF    Network    Building
  187.  7:00 -    10:00 PM Yakima       American Digital Radio
  188.                Society (ADRS)presents a
  189.                technical presentation:
  190.                "A Low Cost DSP Modem for HF Digital 
  191.                            Experimentation" by
  192.                Johan Forrer, KC7WW
  193.  
  194. Sunday,    August 21
  195.  
  196. TIME         ROOM       EVENT
  197.  8:30 -     Noon     Menominee Hospitality & Demo area open
  198. 10:00 -    11:00     Menominee Conference wrap-up and close.
  199.  
  200. ---------------------------------------------------------------------------- 
  201.            13th ARRL Digital Communications Conference Proceedings
  202.  
  203. 1.   A Proposal for a Standard Digital Radio Interface
  204.     Jeffrey Austen, K9JA 
  205.  
  206. 2.   Automatic Packet Reporting System (APRS)
  207.     Bob Bruninga, WB4APR
  208.  
  209. 3.   Broadcast, UI and un-connected protocols-the future of Amateur Packet Radio?
  210.     Paul Evans, W4/G4BKI
  211.  
  212. 4.   Packet, GPS, APRS and the Future
  213.     Paul Evans, W4/G4BKI
  214.  
  215. 5.   Computer Networks in Africa: From Utopian Discourse to Working Reality
  216.     Iain Cook
  217.  
  218. 6.   A Low Cost DSP Modem for HF Digital Experimentation
  219.     Johan Forrer, KC7WW
  220.  
  221. 7.   G-TOR: The Protocol
  222.     Mike Huslig, Phil Anderson, Karl Medcalf and Glenn Prescott
  223.  
  224. 8.   GMON-a G-TOR Monitoring Program for PC Compatibles
  225.     Richard Huslig and Phil Anderson, W0XI
  226.  
  227. 9.   A Theoretical Evaluation of the G-TOR Hybrid ARQ Protocol
  228.     Glenn E. Prescott, WB0SKX, And Phil Anderson, W0XI
  229.  
  230. 10.  On Fractal Compression of Images for Narrowband Channels and Storage
  231.     W. Kinsner, VE4WK
  232.  
  233. 11.  Fast CELP Algorithm and Implementation for Speech Compression
  234.     A. Langi, VE4ARM, W. Grieder, VE4WSG, and W. Kinsner, VE4WK
  235.  
  236. 12.  Wavelet Compression for Image Transmission Through Bandlimited Channels
  237.     A. Langi, VE4ARM, and W. Kinsner, VE4WK
  238.  
  239. 13.  ROSE X.25 Packet Switch Status Update
  240.     Thomas A. Moulton, W2VY
  241.  
  242. 14.  A Primer on Reliability as Applied to Amateur Radio Packet Networks
  243.     T.C. McDermott, N5EG
  244.  
  245. 15.  FSK Modem with Scalable Baud Rate
  246.     Wolf-Henning Rech, N1EOW, and Gunter Jost, KD7WJ
  247.  
  248. 16.  MacAPRS: Mac Automatic Packet Reporting System-A Macintosh Version of APRS
  249.     Keith Sproul, WU2Z, and Mark Sproul, KB2ICI
  250.  
  251. 17.  Formation of the TAPR Bulletin Board System Special Interest Group
  252.     David A. Wolf, WO5H
  253.  
  254. 18.  How Amateur Radio Operators Can Emulate an HF ALE Radio
  255.     David R. Wortendyke, N0WGC
  256.  
  257. 19.  A Preview of HF Packet Radio Modem Protocol Performance
  258.     Teresa Young, Stephen Rieman, David Wortendyke, N0WGC
  259.  
  260. ---------------------------------------------------------------------------
  261. Rev. 7/12/94
  262. [EOF]
  263.  
  264.  
  265. ----- End of forwarded message -----
  266.  
  267. ------------------------------
  268.  
  269. Date: Wed, 13 Jul 1994 10:57:18 -0500
  270. From: David Rush <rush@erg.sri.com>
  271. Subject: Bridge vs. Repeater
  272. To: tcp-group@UCSD.EDU
  273.  
  274. Steve said:
  275. >The argument that a router would be better than a repeater is off a
  276. >bit, as it assumes the user wants to route.  Some may just want to chat, 
  277. >or hook up with a (gulp) BBS...  In this case the repeater attempts to 
  278. >solve the hidden node problem, but so could DAMA, for a lot less.
  279.  
  280. Well, isn't there a bit more than that?  Even if two nearby users don't
  281. care about routing, a router can keep two local users from sucking up
  282. bandwidth... I'll share this with the group...
  283.  
  284. I said:
  285. >> Yeah, presumably cross- or multi-banding would probably make the most
  286. >> sense (easiest).  All of the stations in a "mutually hearable area" 
  287. >> would share one freq on one band.  The stations in a different 
  288. >> "mutually hearable area" (on the other side of the mountaintop 
  289. >> router) would share a different freq on a different band.
  290.  
  291. Then Gerry said:
  292. >So, why not use a wide area machine on 2 in-band frequencies, using the 
  293. >regen? It's a "repeater" to the FM guys, simple to maintain, simple to 
  294. >build, simple to install.  Find a good {tower/building top/mountain top} 
  295. >and put it up to cover as much of the are as possible.  If you THEN have 
  296. >an area that's not adequately covered, put up another regen in that area 
  297. >on the reverse channel, or route over to that remote area.
  298.  
  299. Because traffic between two stations on the left side of the mountain would
  300. generate useless traffic (thru the regen) on the right side of the mountain.
  301. (Sucking up bandwidth.)  A router could decide which packets need to cross 
  302. over the mountain, but otherwise stay quiet.
  303.  
  304. Assuming that nobody even cares about routing in this case, what I'm
  305. really proposing is a bridge (to use Ethernet terminology) between
  306. the two sides of the mountain, rather than bit regenerator.
  307. And when we say "bit regenerator", it's functionally equivalent to an 
  308. Ethernet repeater, aren't we?
  309.  
  310. David
  311. ---------------------------------------------------------------
  312. David Rush, SRI International, Leavenworth, Kansas 913-682-9101
  313. rush@erg.sri.com, david@n0oxh.ampr.org
  314.  
  315. ------------------------------
  316.  
  317. Date: Wed, 13 Jul 1994 17:47:06 +0100
  318. From: "Brian A. Lantz" <brian@lantz.cftnet.com>
  319. Subject: Managing MSS and Window; IP encapsulation
  320. To: TCP Group Mailing List <tcp-group@ucsd.edu>
  321.  
  322. On Wed, 13 Jul 1994, Phil Karn wrote:
  323.  
  324. > Can people tell me whether the receive-side change has made it yet to the
  325. > NOS variants that people are using as wormhole gateways? Or do I need
  326. > to keep 94 on the transmit end a little longer to avoid compatibility
  327. > problems?
  328. > 
  329.  
  330. TNOS, based on an earlier version of JNOS, only checks for receiving 94. 
  331. It's funny that this came up today, since I was looking at a couple of 
  332. different IPIP listings (including xNOS) to see what differences there 
  333. were, since I'm looking into figuring out the patches needed to do it 
  334. under Linux.
  335.  
  336. Phil's is the only one I KNOW about that checks also for a '4'.
  337.  
  338.  
  339. -----------------------------------------------------------
  340. Brian A. Lantz/KO4KS                 brian@lantz.cftnet.com
  341.  
  342. REAL PORTION of Microsoft Windows code:
  343.     while (memory_available)    {
  344.         eat_major_portion_of_memory (no_real_reason);
  345.         if (feel_like_it)
  346.             make_user_THINK (this_is_an_OS);
  347.         gates_bank_balance++;
  348.     }
  349.  
  350. ------------------------------
  351.  
  352. Date: Thu, 14 Jul 1994 02:32:33 -0700
  353. From: Phil Karn <karn@qualcomm.com>
  354. Subject: Managing MSS and Window; IP encapsulation
  355. To: A.Cox@swansea.ac.uk
  356.  
  357. IPNG is, in my opinion, years in the future. Beyond my current
  358. horizon, anyway.  And even if it wasn't, it's still worth doing for
  359. IPv4. One situation in particular could really benefit: tunnel
  360. encapsulation. A maximum sized packet being encapsulated could easily
  361. generate two fragments, one maximum sized and the second very small.
  362. Path MTU discovery could help avoid this.
  363.  
  364. What do you mean by MTU discovery breaking? I know that many routers
  365. don't yet indicate the interface MTU when they bounce a too-large
  366. packet with DF set. I plan to handle that by stepping through a table
  367. of common MTU values.
  368.  
  369. My only concern about path MTU discovery is exactly how often I should
  370. try to increase the MSS to probe for a possible route change after it
  371. has been decreased. Given the relatively static routes on the net I
  372. would probably say "rarely", but I don't like hard-coded values in
  373. protocols that are supposed to be self-scaling.
  374.  
  375. Phil
  376.  
  377. ------------------------------
  378.  
  379. Date: Thu, 14 Jul 1994 10:50:44 +0200 (BST)
  380. From: A.Cox@swansea.ac.uk (Alan Cox)
  381. Subject: Managing MSS and Window; IP encapsulation
  382. To: karn@com.qualcomm (Phil Karn)
  383.  
  384. > What do you mean by MTU discovery breaking? I know that many routers
  385. > don't yet indicate the interface MTU when they bounce a too-large
  386. > packet with DF set. I plan to handle that by stepping through a table
  387. > of common MTU values.
  388.  
  389. A measurable number of low grade routers simply 'lose' oversized packets. I've
  390. had several network problems I have chased down to MTU discovery on SYS5.4
  391. machines failing because routers on the way simply ate any oversized frames
  392. without sending back an ICMP or sending back an icmp with a hop count of 16
  393. that never arrives back. I suppose the answer to this is 'tcp discovery off'
  394. as a KA9Q command 8).
  395.  
  396. > My only concern about path MTU discovery is exactly how often I should
  397. > try to increase the MSS to probe for a possible route change after it
  398. > has been decreased. Given the relatively static routes on the net I
  399. > would probably say "rarely", but I don't like hard-coded values in
  400. > protocols that are supposed to be self-scaling.
  401.  
  402. An off the cuff suggestion would be when you see a significant shift in 
  403. round trip time for a measurable duration being one. Another clue would be
  404. the hop count on received tcp frames changing, and the third obvious one is
  405. if your local route table shifts.
  406.  
  407. Alan
  408.  
  409. ------------------------------
  410.  
  411. End of TCP-Group Digest V94 #148
  412. ******************************
  413.